JAM utilises the client-server model. This architecture was chosen for a number of reasons. Firstly, having a central server means that clients only need to connect to one point, compared to a peer-to-peer system in which clients themselves must connect to each other. Secondly, the server can then act as a safety buffer between the clients, relaying only the data that is actually relevant and valid. Thirdly, the server also acts as a central authority for user accounts, allowing information about a particular user to be returned even if they are offline or if they login for another machine without their own settings.

However, there are disadvantages to the client-server architecture. By adopting this model, we are creating a bottleneck in the network - all messages and transactions must be passed through the server. This should not be a problem given the scale of our project, and similar systems operate multiple servers to handle client connections. In addition to this, we have created a single point of failure, in that should the server become unavailable, clients will not be able to communicate with each other.

With the client-server architecture, the two major components are the client and server. The server handles multiple connections to and from clients, and clients have one connection to the server. These components interact with each other using a protocol. These three components are defined in the sections which follow.

class and component diagrams
